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METHODS AND SYSTEMS FOR ASSESSING 
LOAN PORTFOLIOS 

BACKGROUND OF THE INVENTION 

[0001] This invention relates generally to assessing loan portfolios, 
and more specifically, to assessing collections variance in non-performing loan 
portfolios. 

[0002] The term "loan portfolio" refers to a group of loans related by, 
for example, market segment or a geographic market. For example, a loan portfolio 
may consist of thousands of automobile loans in a particular country. A non- 
performing loan portfolio is a loan portfolio in which each loan is in late stages of 
delinquency (i.e., has many payments due). The term "variance" refers in this context 
to a difference between actual payments and planned payments arising from a re- 
negotiation. 

[0003] A lender may have many non-performing loans (e.g., 10,000 
to 20,000 loans) having a total value of billions of dollars, worldwide. Management 
of non-performing loan portfolios typically involves monitoring the productivity and 
yield of the overall collection process, and its constituent steps. More specifically, 
managing non-performing loans involves administration of the following matters: 

status of borrower negotiations, as asset managers work with borrowers 
through a series of standard settlement milestones, 

annual business plans established for each borrower in each portfolio, 
ascribing the expected amount and timing of cash flows, and collection 
method strategy, 

actual monthly payments made by each borrower to retire the debt, and 

account characteristics (borrower, loan, collateral, asset manager). 

[0004] A lender may seek investors to participate in the risk and 
rewards associated with acquiring and managing non-performing loan portfolios. 
Among typical investor requests in connection with non-performing portfolios the 
-1- 



17243-00042 



investor owns, or is considering investing in, are forecasts of monthly amounts 
collected for each portfolio up to one year in advance, as well as detailed explanations 
of actual differences or variances from the targeted, or planned, collection amounts. 

BRIEF SUMMARY OF THE INVENTION 

[0005] In one aspect, a method for assessing a loan portfolio for 
variance is provided. In an example embodiment, the method comprises the steps of 
identifying a milestone for at least one loan in the portfolio at a selected time of 
assessment, determining planned collections for the loan for the selected time of 
assessment, determining actual collections for the loan for the selected time period of 
assessment, and populating a spreadsheet identifying a current milestone and a 
cumulative variance between planned collections and actual collections at the 
milestone for the loan. 

[0006] In another aspect, a database for a variance tracking system is 
provided. The database comprises a memory storage having data stored therein, and 
the data comprises a milestone status for each of a plurality of loans, planned 
payments for each loan, actual payments for a plurality of loans, and indexes of time 
associated with each planned payment and with each actual payment. 

[0007] In yet another aspect, a computer program for controlling 
operation of a computer to determine variance in a loan portfolio is provided. In an 
example embodiment, the computer program is executable to control the computer to 
associate each loan in the portfolio with one of a plurality of milestones, determine 
cumulative planned collections for a selected loan for the selected time of assessment, 
determine cumulative actual collections for the loan for the selected time period of 
assessment, and determine a cumulative variance for the loan for the selected time 
period of assessment based on the cumulative planned collections and cumulative 
actual collections. 

[0008] In still yet another aspect, a variance tracker system for 
tracking variance in a loan portfolio is provided. The system comprises a database 



-2- 



comprising a memory storage having data stored therein. The data comprises a 
milestone status for each of a plurality of loans, planned payments for each loan, 
actual payments for a plurality of loans, and indexes of time associated with each 
planned payment and with each actual payment. The system further comprises a 
processor coupled to the database. The processor is programmed to associate each 
loan in the portfolio with one of a plurality of milestones, determine cumulative 
planned collections for a selected loan for the selected time of assessment, determine 
cumulative actual collections for the loan for the selected time period of assessment, 
and determine a cumulative variance for the loan for the selected time period of 
assessment based on the cumulative planned collections and cumulative actual 
collections. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0009] Figure 1 is block diagram of one embodiment of an asset 
management information system; 

[001 0] Figure 2 is a process map for tracking portfolio variance; 

[001 1] Figure 3 illustrates normalization of an initial plan matrix; 

[00 1 2] Figure 4 illustrates coding planned payments; 

[0013] Figure 5 illustrates coding actual payments; 

[0014] Figure 6 illustrates indexing time of assessment; 

[001 5] Figure 7 illustrates matching and cumulative variance; 

[0016] Figure 8 illustrates transition inventories; 

[00 1 7] Figure 9 illustrates a transition inventory display; 

[001 8] Figure 1 0 is a screen shot of an example user interface; 



[0019] Figure 11 is a screen shot of a date selection screen for use in 
connection with the example user interface shown in Figure 10; 

[0020] Figure 12 is a screen shot of another example user interface; 

and 

[0021] Figure 13 is a screen shot of an example user interface in 
connection with importing files into the database. 

DETAILED DESCRIPTION OF THE INVENTION 

[0022] Set forth below is a description of an information 
management system for tracking portfolio variance of non-performing loan portfolios. 
The technical effect produced by the system is the generation of a spreadsheet for 
analyzing and understanding variances between planned and actual performance at the 
portfolio level, and improved forecast capability for near and long term. 

[0023] In an example embodiment, the variance tracking system is 
implemented on a personal computer in a Microsoft Office operating system 
environment. Microsoft Office software is commercially available from Microsoft 
Corporation, Redmond, Washington. A spreadsheet program, such as Excel (also 
commercially available from Microsoft Corporation) is loaded into the personal 
computer. A data management system, such as Access (also commercially available 
from Microsoft Corporation) also is loaded into the personal computer. Of course, 
other operating systems, other spreadsheet programs, and other data management 
systems can be utilized. In addition, the processor need not be in the form of a 
personal computer. The processor selected need only be capable of performing the 
processing described herein to be utilized. 

[0024] The example system described below tracks plan versus 
actual collections for non-performing loan portfolios. In addition, the system enables 
an end-user to dynamically rank portfolio segments (or borrowers) by their 
contribution to plan versus actual collections variance. 
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[0025] Referring now specifically to the drawings, Figure 1 is a block 
diagram illustrating an example embodiment of an information system for variance 
tracking. A system server provides users with access to operational information for 
asset management, recorded into a data warehouse in an ongoing basis from other 
applications residing on a network, e.g., a local area network. The data warehouse, in 
an example embodiment, is an Oracle database, commercially available from Oracle 
Corporation, Redwood Shores, California. 

[0026] The information stored in data warehouse includes, for 

example: 

Borrower Contact Information, 
Contact Action / Results History, 

Borrower Characteristics (e.g., size of outstanding balance, nature of 
collateral security, lien information, historical payment performance, 
litigation status, and underwritten valuation), and 

Asset Management Milestones (with corresponding dates and expected 
"recovery" amounts where appropriate*): Not Contacted, In 
Negotiation, Scheduled for Approval, Approved*, Approved 
Delinquent, Closed*, Closed Delinquent, Paid-In-Full, and 
Foreclosed*. 

[0027] Portfolio administrators construct periodic (e.g., annual, 
quarterly) business plans for debtor groups (e.g., individuals, borrower alliances, and 
portfolio segments). The business plans include the expected monthly cash payments 
made by the debtor groups. The time horizon (beginning month to ending month) of 
the business plans for each debtor group is the same (e.g., January 2001 to December 
2005). 

[0028] Portfolio administrators choose among various available 
borrower, loan, and collateral characteristics pertaining to the debtor group. These 
characteristics are used for subsequent "data mining" purposes (e.g., prioritizing 
debtor groups, stratified by their common group characteristics, according to each 
stratum's contribution to an overall variance calculation as described below). 
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[0029] Once debtor groups have progressed through asset milestone 
phases and achieve a negotiated settlement (i.e., are "closed"), loan servicing issues 
notification of contractual cash payments. As payments are received, they are posted 
in a cash management system, from which general ledger accounting entries are made. 
For non-performing loans, these contractual cash flows usually sum to considerably 
less than the balance owed to the original credit issuer. A purchaser of non- 
performing loan portfolios (from the original credit issuer or subsequent purchaser) 
aims to collect more than his/her purchase price for each debtor group in the portfolio. 

[0030] The systems and methods described herein facilitate 
determining how well the periodic business plans are borne out in reality and in 
addition, allow for the identification of portfolio segments (strata) which are the chief 
contributors to slippages (or accelerations) in actual payments made, as compared to 
the business plans (or contractual cash flows). These functions are sometimes referred 
to herein as variance tracking. Such functions are performed in the system illustrated 
in Figure 1 by the variance tracker database (illustrated in Figure 1 and sometimes 
referred to herein as the variance tracker DataMart) and the variance tracker client. 
More specifically, data from data warehouse and from the business plans is stored in 
database, and variance tracker client is an application program executed by the 
personal computer to perform the functions described above (i.e., variance tracking). 

[0031] More particularly, and referring to Figure 2, variance tracker 
database, i.e., DataMart, is created by performing certain tasks on an annual/quarterly 
and monthly basis. For example, business plans are created on an annual or quarterly 
basis. The DataMart is data stored on the personal computer memory utilizing the 
data management system (e.g., the Access data management system), as described 
above. The plans are comprised of expected monthly cash flows for each debtor 
group, and are uploaded to variance tracker DataMart. Business plans can be for a 
single borrower, borrower alliances, and portfolio segments. 

[0032] The business plans are usually created in a normalized format 
(i.e., a matrix format - with debtor group ZD's in rows, and monthly expected 
payments in columns). The normalized format is converted to a de-normalized, or 
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list-oriented, version of the business plan. The number of months between a starting 
month and each payment month - a Time Series ID - is assigned (i.e., monitoring may 
start in January, 2001, and payments made in May, 2001, June, 2001, or months 5 and 
6, respectively) to each plan. De-normalization occurs each time business plans are 
uploaded. 

[0033] On a monthly basis, debtors progress through a standardized 
series of asset milestones. Monitoring the transition of borrowers through these 
critical junctures provides indication of the asset management performance. The asset 
milestone progress therefore is tracked and organized by asset ID. In addition, actual 
cash collections in each month are uploaded and assigned a Time Series ID. The 
cumulative cash collections (Cume Cash Collections) are organized by SubAsset ID 
and by Asset ID in a table format. As cash payments may be tracked at a different 
level (e.g., by loan) than that of other database entities (e.g., asset milestones, data 
mining characteristics, business plans), a map associating these different levels (ID 
Maps) is updated and uploaded. Specifically, the ID Map associates Asset ID and 
SubAsset ID to specific loans. Expected payments from business plans for each 
debtor group, for each time series ID is associated, or linked, with actual payments, 
aggregated from SubAsset ID to Asset ID (debtor group ID) by Time Series ID. 

[0034] Appendix A contains database schematics (DS) that can be 
utilized in building one example embodiment of variance tracker DataMart.. 
Specifically, DS 1 is a database schematic for the CFIDs (a.k.a., "Cash Flow ID's"), 
DS 2 is for payment data, DS 3 is for approved (i.e., accepted by investors) business 
plans, DS 4 is for large (i.e., borrowers with large balances) business plans, DS 5 is 
for buckets (i.e., portfolio segments) business plan, DS 6 is for business plan totals, 
DS 7 is for milestones, DS 8 is for CFIDs without business plans, DS 9 is for variance 
tracking data, DS 10 is for variance tracking data, DS 10 is for subtype export data, 
and DS 1 1 is for subtype export data. 

[0035] Once a DataMart is created, then a variance tracker client is 
utilized to generate a transition inventory matrix, which illustrates key portfolio 
statistics and variance calculations for any selected (drilled-down) segment of the 
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portfolio, and by asset milestone one-month status changes. The matrix is generated 
by the personal computer using, for example, the Excel spreadsheet program, as 
described above. A transition inventory matrix can be created for any historical 
month, beginning with the first month of portfolio monitoring. Using the transition 
inventory matrix, sources and movements over time of borrowers, payments, and 
variances can be assessed. Such assessment can be utilized to better identify asset 
management process improvements, resulting in an improved ability to manage 
strategic operations. 

[0036] Figures 3-9 illustrate one example of creating DataMart and 
constructing a transition inventory matrix. More particularly, Figure 3 illustrates 
normalization of a business plan. Specifically, from an initial plan matrix which 
depicts accounts (rows) across plan months (columns), normalization creates a list- 
oriented format which is useful for subsequent matching. 

[0037] Planned payments are then coded as illustrated in Figure 4. 
Such coding refers to translating the contents of a time field (in the example, a 
"Month") into an index of time, namely, identify the number of months from a 
selected point in time to which the record pertains. For example, if the selected point 
in time is November, 2000 (i.e., November, 2000 = month index 1), then the month of 
January, 2001 corresponds to a month index of 3 as illustrated in Figure 4. 

[0038] Actual payments also are coded, as illustrated in Figure 5. 
The same coding methodology utilized to code the planned payments is utilized to 
code the actual payments. 

[0039] Referring now to Figure 6, and for variance analysis of 
cumulative plan versus actual differences, from a specific point in time through a 
current month (e.g., from November, 2000 through March, 2001), the user must 
specify the index of the time assessment (in the example, month index 5). By so 
specifying the month index, then a transition inventory matrix can be created for 
assessment. 



[0040] Once the month index is specified, then as shown in Figure 7, 
matching and cumulative variance through the specified period of time can be 
determined. Cumulative (cume) variance is the difference between cume plan and 
cume actual up through and including the time of assessment (in the example, the 5 th 
month index). 

[0041] Referring to Figure 8, the cume variance can be performed for 
any desired time of assessment. Assessments between two different time periods are 
used to create a transition inventory matrix, which illustrates how accounts move 
through a management system, and which accounts are producing the largest 
contribution to cume variance. In the example illustrated in Figure 8, accounts that 
were approved and previously closed currently are producing 28 units of cume 
variance. Accounts that were closed previously and now delinquent are also 
producing this amount of cume variance. 

[0042] Figure 9 illustrates a transaction inventory matrix representing 
an assessment of 3376 accounts. The matrix is created using, for example, the Excel 
spreadsheet program commercially available from Microsoft Corporation, Redmond, 
Washington. The spreadsheet is populated using the data stored in DataMart and 
based on the time period selected by the analyst for assessment. 

[0043] Typically, accounts will advance in management milestones 
from one month (or time of assessment) to the next. Bottlenecks can be identified by 
accumulation of variance. In the example shown in Figure 9, accounts which are 
'prior -to-approval' in both the current and previous periods (1487 accounts) have 
generated the greatest amount of plan versus actual variance (approximately -2MM 
currency units). 

[0044] Using the pivot tables in the Excel program, an analyst can 
"drill down" using account characteristics that may be drivers of variance. More 
particularly, and in the example shown in Figure 9, in the upper left hand cover of the 
pivot tables, five variables are listed. These variables can be used to isolate 
problematic account segments. An analyst simply uses the 'drop down' boxes to 



select an account segment (for example, "Real Estate Secured" as an attribute of the 
characteristic "Collateral Type"). The pivot table is automatically updated to reflect 
the selected segment's contribution to variance. Account segments can be rank- 
ordered in terms of their contribution. 

[0045] Example user interfaces are described below in connection 
with Figures 10-13. Of course, many different formats and selections can be utilized 
for the user interface and the user interfaces illustrated below in Figures 10 - 13 are 
example user interfaces. Figure 10 is a screen shot of an example user interface. A 
date selection (i.e., Today's date is) points to a current date as a default. The date can 
be changed by selecting a drop down button. Once the drop down button is selected, a 
calendar, as shown in Figure 11, is displayed. A new date is selected by 'double 
clicking' on the desired date. Once the date is selected, the user then selects 
"Transistion Inventory with new data". 

[0046] As shown in Figure 12, a user can select "Transistion 
Inventory with existing data", which results in display of a pivot table with the most 
recently accessed data. A user also can select "Transition Inventory with new data", 
which results in display of a pivot table with newly generated data and the selected 
date. A user can also select "View data", which results in display of data for which 
the pivot table is being displayed. A user can also select "View sub-type data", which 
results in display of sub-type data. A user can further select "Import new files into the 
database", which results in importing new data into the system using a user interface 
as shown in Figure 13. 

[0047] As shown in Figure 13, the import new files user interface 
includes a browse selectino button so that a user can select a data file to import. 
Selecting the "Import Sub Asset" button results in importing the sub-asset data from 
the data file. Selecting the import payments buttons (in the example, shown as the 
"Import Silverlake Payments" button) results in importing the payment data. 
Selecting the Import Asset Milestone button results in importing the asset milestone 
data. Selecting the "Back" button results in returning processing to the main interface 
screen (e.g., the screen shown in Figure 10). 
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[0048] The system described above provides an ability to analyze and 
understand variances between planned and actual performance at the portfolio level, 
and improved forecast capability for near and long term. In addition, the system 
provides the ability to adjust portfolio management to improve efficiency, as well as 
analytical data for future (i.e., planned purchases) portfolio valuation and acquisition. 

[0049] While the invention has been described in terms of various 
specific embodiments, those skilled in the art will recognize that the invention can be 
practiced with modification within the spirit and scope of the claims. 
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